Starting Julia loads Julia kernel and Base
module. The Base
(core) is kept small and all other functionality is accessible through packages which need to be individually included by the user.
Currently there are 1500+ registered packages listed at Julia Package Listing.
In this notebook, we demonstrate how to use packages.
Read section Packages of the Julia manual (15 min).
The reader should be able to install and use registered and unregistered packages and create own packages.
Some examples are taken from The Julia Manual.
In [1]:
?Pkg.status()
Out[1]:
In [2]:
# This is slow due to communication with GitHub
Pkg.status()
Pkg.add()
This command adds registered package from Julia Package Listing.
Adding the package downloads the package source code (and all other required packages) to your .julia/v0.6/
directory.
GitHub repository names of registered Julia packages always end with the extension .jl
, which is ommited in Pkg.add()
command. The example below installs the package from the GitHub repository https://github.com/JuliaLang/LightGraphs.jl.
N.B. There are other registered packages dealing with graphs, please check them out.
In [3]:
?Pkg.add
Out[3]:
In [4]:
# Pkg.add("LightGraphs")
In [5]:
# This is Julia's default directory
# Windows version: a=readdir("/Users/Ivan/.julia/v0.6")
a=readdir("/home/slap/.julia/v0.6")
Out[5]:
In [6]:
println(a)
We now have directory /Users/Ivan/.julia/v0.6/LightGraphs
. Let us examine its content
(this can also be done directly from the GitHub repository https://github.com/JuliaLang/LightGraphs.jl).
Each package has the following three files:
REQUIRE
README.md
is the Markdown file, which contains the descritption of the package as displayed on the repository's home page.LICENSE.md
contains the licensing information.The file travis.yml
, if present, defines how is the package tested on Travis-CI after every posted change (via git push
command).
Details on using Travis-CI for Julia projects are at
https://docs.travis-ci.com/user/languages/julia. Since testing is done on machines other than yours, with operating systems other than yours, and using Julia version which may differ from yours, this is a great way to correct bugs, and also a way to give users examples of how to run your code.
The src/
directory contains the actual code of your package.
It must contan the file named as the package itself, src/LightGraphs.jl
in this case, which containd the following:
module
line starts the description of the main module, which has the same name as the package,using
line(s) lists other registered packages used by the package. These packages are also listed in the REQUIRE
file.import
line lists the other modules and their components which are modified in this moduleexport
line lists all component which will be accessible directly in the main namespace. The components which are not exported, can still be used but the full name (including mogule name) must be usedinclude()
commands include the source filesend
concludes the description of the module.If Travis-CI is used, the test/
directory contains the file runtests.jl
which is exaceuted during the testing, and, eventually, other files that this file is calling.
The doc/
is optional and is used to store documentation.
The deps/
directory is optional and is used to store dependencies if the package is using software written in other languages. There are many examples which can be checked out.
using
and import
Package needs to be added only once, prior to the first use. We are now ready to use the package.
We have two methods to do so, which differ in their treatment of the namespace:
using
adds all methods, constructors etc. from the package into the main namespace, so they can be called directly, like the function add_edge!()
below.import
enables us to use all the methods, constructors, etc. from the package, but they are not included in the namespace, so they must be called together with the package name,
LightGraphs.add_edge!(4)
.N.B. import
can also be used on a particular function(s), as we shall explain later.
In [7]:
using LightGraphs
In [8]:
whos(LightGraphs)
Let us construct the famous graph of the Seven Bridges of Königsberg, plot it, and compute the number of different walks which cross 3 bridges between the north side and the center island. Can you enumerate the walks?
To work with weighted graphs and to plot we also need the following two packages, respectively.
In [9]:
using SimpleWeightedGraphs
using GraphPlot
We first create s simple graph, and later switch to the weighted version.
In [10]:
g=Graph(4)
Out[10]:
In [11]:
add_edge!(g,1,2)
add_edge!(g,1,2)
add_edge!(g,1,3)
add_edge!(g,1,3)
add_edge!(g,1,4)
add_edge!(g,2,4)
add_edge!(g,3,4)
g
Out[11]:
In [12]:
gplot(g, nodelabel=1:4)
Out[12]:
The package ignores multiple edges, so will emulate them with weights.
In [13]:
gplot(g,nodelabel=1:4, edgelabel=[2,2,1,1,1] )
Out[13]:
In [14]:
# Number of edges and number of vertices
nv(g), ne(g)
Out[14]:
In [15]:
has_edge(g,(1,2))
Out[15]:
In [16]:
?edges
Out[16]:
In [17]:
edges(g)
Out[17]:
In [18]:
(1,2) in edges(g), (3,2) in edges(g)
Out[18]:
In [19]:
# This is not what we want
A=adjacency_matrix(g)
Out[19]:
In [20]:
full(A)
Out[20]:
We switch to weighted graph.
In [21]:
g=SimpleWeightedGraph(4)
Out[21]:
In [22]:
add_edge!(g,1,2,2)
# add_edge!(g,1,2,2)
add_edge!(g,1,3,2)
# add_edge!(g,1,3)
add_edge!(g,1,4,1)
add_edge!(g,2,4,1)
add_edge!(g,3,4,1)
g
Out[22]:
In [23]:
has_edge(g,(1,2))
Out[23]:
In [24]:
edges(g).f((1,2,2))
Out[24]:
In [25]:
# Be carefull!
(1,2) in edges(g).iter, (3,2) in edges(g)
Out[25]:
In [26]:
W=weights(g)
Out[26]:
In [27]:
full(W)
Out[27]:
In [28]:
no_of_walks=(W^3)[1,2]
Out[28]:
The contents of a registered package obtained by the command Pkg.add("Package_name")
is fixed at the time of registration.
The package owner may further develop the package, but those changes are not registered (until the registration of a new version).
If you want to use the latest available version, the command Pkg.checkout("Package_name")
downloads the latest master.
Adds unregistered packages or repositories. Here the full GitHub address needs to be supplied. As an example, we shall use the package LinearAlgebra.jl.
N.B. In Julia, the linear algebra routines are incorporated as wrappers of various LAPACK . This package contains several routines written directly in Julia.
By inspecting the file src/LinearAlgebra.jl
, we see that nothing is exported so all methods need to be fully specified. We also see that the SVD related stuff may be in the file
src/svd.jl
. There we see that the sub-module SVDModule
is defined, but with nothing eported, and we must specify the full command LinearAlgebra.SVDModule.svdvals!()
.
We shall compute the singular values of the bidiagonal Jordan form with the standard Julia function svdvals()
and the function from the package.
In [29]:
# Pkg.clone("https://github.com/andreasnoack/LinearAlgebra.jl")
In [30]:
using LinearAlgebra
In [31]:
# Not much of an information
whos(LinearAlgebra)
In [32]:
# Also no information
whos(LinearAlgebra.SVDModule)
In [33]:
methods(LinearAlgebra.SVDModule.svdvals!)
Out[33]:
In [34]:
# We now know how to define bidiagonal matrix
methods(Bidiagonal)
Out[34]:
In [35]:
n=70
c=0.5
J=Bidiagonal(c*ones(n),ones(n-1),true)
Out[35]:
In [36]:
@time s=svdvals(J);
Julia uses convention that function names ending in !
overwrite the input data.
Thus, we first make a copy of J
.
In [37]:
J₁=deepcopy(J);
In [38]:
J₀=Bidiagonal([1.0,1,1],[1,1],true)
Out[38]:
In [39]:
LinearAlgebra.SVDModule.svdvals!(J₀)
Out[39]:
In [40]:
@time s₁=LinearAlgebra.SVDModule.svdvals!(J₁);
In [41]:
typeof(s₁), s₁
Out[41]:
In [42]:
s[70], s₁[70]
Out[42]:
In [43]:
# Pkg.rm("LightGraphs")
In [44]:
# Pkg.rm("LinearAlgebra")
You need to use GitHub:
Sign up
and Sign in
.N.B. Check out GitHub Guides.
One way to start developing packages is
git clone https://github.com/your_user_name/your_repository_name.jl
git commit
git add file1 file2 ...
git commit
git push
N.B. There are various other possibilities and shorthands (see the Guides). For example, steps 4., 5. and 6. can be shortened with
git commit -am "your message"
Also, if you work on your package from two computers, you may need to synchronize your repository: assume that you pushed the changes that you made on computer A to GitHub, and that you want to continue to work on your repository from computer B. Then, you obviously need to synchronize computer B with the latest version from GitHub. This is done with the following commands issued on computer B:
git fetch origin
git reset --hard origin/master
git clean -f -d
You can fork other people's repositories, and use them and change them as your own. You can make pull requests to incorporate those changes to those repositories.
You can easily make different branches of your repository, and test different options.
GitHub enables you to share your work with others, so even small, undocumented packages can be very useful.
In [ ]: